Hosting services provide a means whereby multiple users can implement custom server configurations without the overhead costs associated with purchasing, upgrading, and maintaining equipment needed to implement the configuration. Instead, a hosting service provider maintains and provisions a grid of hardware nodes that are shared amongst the multiple users. More specifically, resources of a single node can be partitioned and each of these partitions can be allocated to host a virtual server configuration of a different user.
Each hardware node in the grid includes one or more processing units (e.g., a CPU, multiple CPUs, CPUs with multiple processing cores, ASICs, graphics processing units, etc.), memory, block devices (e.g., disk storage devices), networking capabilities, and other such computing resources that often exceed the computing resources required by any single user's server configuration. By partitioning the resources of a hardware node amongst multiple server configurations, a hosting service provider minimizes the amount of hardware needed to host all such server configurations, while maximizing the usage of the available hardware.
Virtualization provides the means for partitioning the hardware resources amongst the multiple server configurations. Virtualization creates the façade that each server configuration is individually hosted on dedicated equipment with a particular set of resources. Two or more server configurations are provided non-conflicting sets of resources of the same hardware node such that a guaranteed amount of processing resources is available to each such configuration. In other words, a single physical resource is partitioned to operate as multiple logical resources.
As shown in FIG. 1, virtualization allows a single computing device 110 the ability to function as two or more different computing devices with each device having distinct sets of hardware resources and software resources. For instance, configuration 120 may be allocated 40% of the memory and 80% of the processor cycles of the device 110 and configuration 130 may be allocated the remaining 60% of the memory and 20% of the processor cycles of the device 110. Additionally, the configuration 120 may operate using a first operating system with a first set of configuration parameters and the configuration 130 may operate using a second operating system with a second set of configuration parameters.
An added benefit of virtualization is that a failure in one configuration does not disrupt the operation of the other configurations, even though all such configurations operate over physical resources of a single device. With reference to FIG. 1, should the configuration 120 crash due to an improper configuration of the operating system, the configuration 130 will continue operating unhindered as the resources used by each configuration 120 or configuration 130 operate independent of one another.
At the core of each virtualization solution is the hypervisor. The hypervisor, also referred to as the virtual machine monitor, manages a logical partitioning of a physical set of hardware resources of a physical device or node between different virtualized guests. Each virtualized guest implements one or more virtual machines over a logical partition. The hypervisor partitions underlying hardware resources such that each virtual machine is provided what logically appears as a distinct and unshared set of hardware resources. However, the hypervisor maps the virtual machine hardware calls to a corresponding subset of physical hardware resources that are actually shared by all virtual machines operating on a particular hardware node. The hypervisor is thus responsible for mapping the hardware resources of a node to a set of virtual resources. The set of virtual resources can then be distributed independently to one or more operating systems or applications that together form the one or more virtual machines. In this manner, each virtual machine effectively is provided its own resources (e.g., a processor, memory, disk storage, networking, etc.), and the operating system of each virtual machine operates with little to no change over the provided set of resources.
Different vendors implement hypervisors differently (e.g., Xen®, Parallels®, VMware®, Kernel Virtual Machine® (KVM), etc.). Two prominent hypervisor types are defined as “type 1” hypervisors and “type 2” hypervisors. FIG. 2 illustrates a type 1 hypervisor 210 of a prior art virtualization implementation. In this figure, the type 1 hypervisor 210, is located at a layer below domain 0 (Dom0) 225, where Dom0 225 is the first domain or virtual machine started by the hypervisor on boot. Other virtual machines that execute one or more different guest operating systems and one or more applications in conjunction with the type 1 hypervisor 210 are enumerated as Dom1 through DomN 230.
As shown, the type 1 hypervisor 210 is located between the various Doms and the hardware resources 220. The type 1 hypervisor 210 controls access to the hardware resources 220. Accordingly, there is only a single layer of abstraction between the type 1 hypervisor 210 and the hardware resources 220.
FIG. 3 illustrates a type 2 hypervisor 310 with a host operating system (OS) as Dom0 320. The host OS at Dom0 320 operates at a layer between the type 2 hypervisor 310 and the hardware resources 330. In this configuration, Dom0 320 is provided special access to the hardware resources 220 while Doms 1-n are unprivileged domains that by default are not provided direct access to the hardware. In this figure, there are two layers of abstraction between the type 2 hypervisor 310 and the hardware resources 330 since the host OS 320 directly controls the hardware resources 330 of the electronic device. Therefore, the type 2 hypervisor 310 utilizes a combination of host OS calls and direct hardware calls to facilitate the logical partitioning of the hardware resources 330 of the electronic device in order to allow for the simultaneous and non-conflicting operation of multiple virtual machines represented as Doms 1-n 340.
In some instances, a type 1 hypervisor more efficiently performs a set of operations issued by a virtual machine over the hardware resources of a node than a type 2 hypervisor. In other instances, a type 2 hypervisor more efficiently performs the set of operations issued by the virtual machine over the hardware resources of a node than a type 1 hypervisor. Each virtualization vendor may implement type 1, type 2, or other hypervisor types differently from other vendors. Each particular vendor may utilize a distinct application programming interface (API) with a distinct set of commands in order to provide virtualization. Therefore, even hypervisors of the same type that are implemented differently by different vendors may have different performance parameters.
Even though current virtualization solutions (i.e., hypervisors) allow hosting service providers the ability to better utilize their hardware resources on individual nodes, these solutions nevertheless lack the functionality needed to create a diverse multi-node hosting service grid operable with multiple different hypervisors. Each hypervisor of the prior art virtualization solutions operates independent of other hypervisors and other nodes. The calls and interfaces of the various hypervisors are not cross-compatible. Therefore, a hosting service is unable to provide a unified grid of nodes that leverages the flexibility and efficiencies of each of the various different hypervisor implementations.
FIG. 4 illustrates proprietary hypervisor managers 410 and 420 implemented by some prior art virtualization solutions to automate the interaction with one or more hypervisors 430 and 440 across the node grid 450. As noted above, these proprietary hypervisor managers 410 and 420 only interface with a single hypervisor from a single virtualization software provider. Therefore, each proprietary manager 410 and 420 is administered separately from the others. Such separate administration partitions the node grid 450 rather than unifies the grid. Additionally, such separate administration does not provide a unified view of the resources of the grid. Instead, each proprietary manager provides a disjointed view that makes it difficult to monitor the grid resource usage and availability of resources over the entire grid of nodes.
A further shortcoming of current virtualization solutions is that the hypervisor and other virtualization components do not provide custom software configurations to automatedly tailor a virtual server configuration per user specifications. In fact, the goal of most hypervisors is to permit the independent operation of the virtual machine such that the virtual machine is wholly unaware of the virtualization occurring underneath. Current hypervisors avoid accessing and modifying the file system of the virtual machine. Accordingly, current hypervisors circumvent the ability to provide automated hosting, requiring system administrators to manually establish and deploy virtual machine configurations.
To attempt to alleviate this issue, some hosting service providers employ a grid management system to retrieve and copy static software images from an image store to the resources allocated for the virtual machine configuration. However, this manner of configuration restricts the ability of hosting service providers to customize the configurations. Specifically, a static set of configurations are available and a “one-size-fits-all” approach is taken to satisfy the requirements of multiple different users. Therefore, after each install, a system operator manually accesses each virtual machine in order to adjust the configurations to create the modified or custom configuration. Such manual operation increases the time needed to deploy a virtual machine configuration and increases the costs associated therewith. For example, the virtual machines are only deployed when a system administrator is present and after the system administrator performs the manual customization to the configuration.
FIG. 5 presents an illustration of a prior art grid management system 510 that copies static software images 520-540 to configure sets of allocated resources on multiple hardware nodes 550-570. In this figure, the grid management system 510 retrieves a static image 520 from an image store 580 and applies the image 520 as retrieved to an allocated set of resources for a virtual machine on node 570. To customize the configuration according to a particular user's specifications, a system operator manually customizes the configuration per the user's specifications.
FIG. 5 illustrates still another shortcoming of current virtualization solutions and the grid management system 510 utilized by some hosting service providers. In this figure, the grid management system 510 becomes a bottleneck within the hosting service system. The grid management system 510 is the central point through which all virtual machines on all nodes are configured. As such, each image for configuring each virtual machine first passes through the grid management system 510 before reaching the corresponding node. This causes the nodes to compete for the input/output resources of the grid management system 510. For large configurations or for periods of high traffic volume, the effectiveness of the grid is compromised as delays arise during the configuration of a virtual machine.
Accordingly, there is a need to provide a more robust, automated, efficient, and synergized virtualization solution for multi-node hosting services. Such a virtualization solution should operate over multiple hardware nodes in order to optimally distribute the resources of the multiple nodes amongst multiple different virtual machine configurations irrespective of the hypervisors operating on each node. There is further a need for such a virtualization solution to automatedly custom configure partitioned resources without manual user intervention based on user-specified parameters for a virtual machine configuration irrespective of the quality or quantity of user customization.